IBIS Macromodel Task Group Meeting date: 25 October 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to send out a proposal for modification of the existing rules for file names. (IBIS 6.1, Section 3, item 3) - Done. - Michael Mirmak to draft a clarification BIRD for AMI Output parameters. - In progress. Michael said he expects to have something soon. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Michael M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Bob Ross and Radek's discussion of Editorial Task Group Issues: - Bob: Summary of the most recent meeting: - Radek prepared draft language for the new [Local Reference] keyword. - Discussion is still ongoing. - Should [External Reference] be included in the "node collapse" rule? - Probably yes. - We discussed pseudo-differential applications and whether [Local Reference] applies. - Starting point for further discussions. - No meeting this week. Relaxation of IBIS filename restrictions: - Walter: [sharing Section 3, item 3., which defines filename requirements] - [sharing his emailed proposal to modify it] - Modifications: - Added capital letters, ".", and "/" to the original character set. - Added a special note with respect to Windows filenames being case insensitive but case preserving. - Added a special note with respect to Linux filenames being case sensitive. - "/" is added for use indicating subdirectories in a file name. - "//", "..", are not allowed. - "/" cannot appear as the first or last character in a file name. - The EDA tool is responsible for converting "/" to "\" if necessary. - This sentence may not be required. - Arpad: You only want to allow subdirectories? - Walter: Yes, I think that's sufficient. - Additional proposal: - I think an eighty character file name is still too constraining. - Should we change it to 256? - We would have to increase line length to 512 in that case. - Bob: That is a separate item. - Is 80 really too constraining for a file name? - Walter: I'm not sure. It might be. - Arpad: Are there any OS restrictions? - Mike L: I believe it's 260 characters on Windows for a network path. - 260 is the limit for the entire path, not just the file name. - Walter: The last paragraph explains that this relaxes almost all file name rules. - Space character " " remains illegal in a filename. - Absolute paths are not permitted. - This statement might be redundant. - Michael M: I think this would address the current IBISCHK BUG 182. - AMI models have relative paths in a file name. (parser doesn't flag this) - Only subdirectories would be allowed. - Bob R: As IBIS exists today, BUG 182 is relevant and not an enhancement. - If this change to file names gets adopted, then we can revisit the parser issues at that time. - As it stands now, certain combinations of "/" in filenames can cause the parser to crash. We don't want to fix that issue yet. - We are very sloppy in IBIS with respect to "file name". - The original statement specified a 40 character basename, a ".", and a three character extension, for a total of 44 character max length. - A search of the IBIS document reveals usage of "file", "file name", and "filename". (.pkg format sections uses "filename"). - This proposal would help with that cleanup. - We should also note that we have reserved extensions for .pkg, .ami, .ibs .ebd, and a pending .ims for the interconnect modeling. Those extensions are preserved, and we should mention it. - The contents of the [File Name] keyword, which exists in IBIS files except .ami, should not be affected by this change to allow relative paths. [File Name] keyword contains a single file name and no path. - IBIS has been sloppy and has a mixture of rules. - In Multi-lingual we make no requirements of file names. - We don't actually require ".dll" and ".so" extensions, though the latest parser might complain if it doesn't see them. - So, the scope of this BIRD could involve a major editorial cleanup of the entire document. - Mike L.: With regard to Windows filenames, I would say that file name resolution is case insensitive, but filename storage is case preserving. - In any event, I don't think IBIS should worry about that issue. - Bob R.: I would be careful with the new verbiage about "Windows file names". - We are introducing a new problem here. There would now be nothing wrong with generating an entire set of Linux models that uses file name case for uniqueness. Placing such a set of models on Windows would could fail. The model maker has to be careful. - Michael M.: We've seen that problem before with .zip or .tar archives expanded on Windows. - Mike L.: That's not unique to IBIS. - Bob: The problem was solved by IBIS strongly suggesting using lower case. - Mike L.: We've run into distributions where every other type of file for a given part used mixed case, but the IBIS files had to avoid it. - Walter: On page 99, [External Model] section, we already allow upper case and recommend caution. - Bob: We have different rules for different formats, and suggestions but not requirements for some. - There are also inconsistencies with DLL_ID and BCI_ID, which allow only "alphanumeric" characters. - This will be a big editorial change. - Michael M.: There will be some overlap and editorial cleanup required. - It's not that different than the [Pin], terminal, etc., wording changes in the interconnect draft. - Walter: [making changes to his proposal based on the discussion] - Added a URL to a wiki page about case_preservation. - Added specific reserved file name extensions. - Noted that filename extensions are case sensitive. - Arpad/Bob R: By "case sensitive" you mean file name extensions should be lower case. - Walter: I don't see any far reaching changes that need to be made elsewhere in the document. - We would have to scrub the document, 500+ plus instances of "file" to review. - Bob: I think that because we were sloppy earlier, this will interact with many areas of the document. - I would suggest this for IBIS 7.0. - Walter: I certainly agree with Bob that this would not be for IBIS 6.2. - Do people agree with this change? - Arpad: The length of file names and line length seemed controversial. - I think file name length factored into line length decisions. - Why do we need a line length limit at all? - Bob: We could have total relaxation and say there are no column length requirements anywhere, but the entire keyword line must fit in the line length limit. - Arpad: Should we consider going to unlimited line length? - What would it require? - Some keywords would have to have "begin" and "end" pairs. - Would it be worth the effort to review all this? - Syntax would define the limits of things instead of hard coded line length limits. - You would need a more rigorous syntax to do it. - It would be more general, instead of having to redo the line length limits every time we want to increase the size of things. - Walter: Making my original change would require very little. - Relaxing length requirements for all keywords might be a big deal for people who do their own parsing. - Going to unlimited would be a big change. People often tend to read things into fixed size buffers. - Increasing a line length from 120 to 256 is probably trivial for the official IBIS parser and other parsers. Going to unlimited is not. - I'd prefer to do the simple thing rather than solve a hard problem that is not a problem. - Bob R.: Going to unlimited, we might as well do a brand new spec. altogether. - That would be way too much. - Walter: I agree with Bob. That would be like making a whole new spec like Touchstone v2, and no one would use it because it's too big a change. - Should I put this proposed file name change into an official BIRD format? - It's not going into 6.2, so there's no rush. - Bob R.: Yes, go ahead and put it in BIRD format. - There might be a substantial review, and it might spawn other BIRDs. - Walter: I don't anticipate that. - I will scrub the document and look for whatever changes need to go into a BIRD. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter to scrub the IBIS spec and prepare a BIRD for the proposed relaxation of file name rules. ------------- Next meeting: 01 November 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives